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REMARKS 



Attorney Docket No.: ZIP00-01 



In response to the Final Office Action mailed on June 16, 2008, 
Applicant(s) respectfully request(s) reconsideration. Claim(s) 1-16 and 18-31 are 
now pending in this Application. Claim(s) 1, 12, 14, 26, 27, 28 and 29 are 
independent claims and the remaining claims are dependent claims. In this 
Amendment, claim(s) 1,12, 14, 26, 27, 28 and 29 have been amended. No new 
matter has been added. Support for the amendments to claims 1 , 12, 14, 26, 
27, 28 and 29 can be found on page 20 lines 15-24 of Applicants' specification, 
Note that in addition to the above cited locations in the specification, support for 
the amendments can be found elsewhere throughout the text and figures of the 
specification as well as elsewhere throughout the specification. 

Applicant(s) believe that the claim(s) as presented are in condition for 
allowance. A notice to this affect is respectfully requested. 

Preliminary Matters 
The Applicants thank the Examiner for the courtesy of a telephone 
interview on August 1 1 , 2008. During the telephone interview, it was discovered 
that the Examiner and the Applicants continue to differ as to their interpretations 
of the teachings of U.S. Patent No. 6,507,866 issued to Barchi ("Barchi"). The 
Applicants contend that the methods taught in Barchi are performed only on 
received messages (on the "receiving side"), such as received by a receiver-mail 
server, and are not performed on outbound messages (on the "sending side") 
transmitted through a originating-mail server, as required by the present claims. 
The Examiner, on the other hand, contends both Barchi and the Applicants' 
invention are performed on an "intermediary." Applicants have included further 
arguments and cites to Barchi that the Applicants believe indicate that Barchi is 
performed only on the receiving side and cites to Applicants' specification and 
figures to indicate that Applicants' invention is performed on the 
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sending/originating side. This enabled Applicant to better prepare a response in 
connection with the claims. Applicants have further amended the claims to clarify 
the distinction between the originating side and receiving side of the email 
process. 

Claim Rejections - 35 USC § 103 

Claims 1-16 and 18-31 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Stark et al. (U.S. 2003/0233420) in view of Barchi (U.S. 
6,507,866). 

As an initial matter, the Office Action does not appear to recognize the 
distinction between receiving side and the originating side of the email delivery 
process as described by the Applicants. Applicants describe that distinction as 
follows: 

"Though less pronounced than the aforementioned examples, other 
deficiencies with conventional techniques used to limit unsolicited 
messages in a computer network exist as well. Since such techniques are 
recipient based techniques (i.e., are performed at the message 
receiving computers), the computer network itself (i.e., the data 
communications equipment), each recipient network service provider 
(e.g., recipient e-mail server) and each recipient computer system (e.g., 
the recipients personal computer) are all burdened by the processing 
required to handle the unsolicited e-mail messages. 

Conversely , the system of the invention is based in part on the 
observation of the aforementioned limitations of conventional message 
limiting techniques and serves to significantly overcome such limitations. 
To do so, the system of the invention provides a message quota 
transmission system which is enforced on the sending side of messaging 
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systems. That is, the system of the invention enforces message quotas 
on computer users who originate outbound messages for transmission 
onto a computer network ." (Page 7, lines 3-14) (Emphasis added) 

Furthermore, the Barchi reference cited by the Examiner makes a similar 
distinction by referring to "sending SMTP server," "receiving SMTP server," 
"received e-mail messages," "incoming e-mail messages," and "originators 
sending e-mail messages." 

Applicants' Fig. 1 delineates the separation between the sending side and 
receiving with the computer network reference character 130. Applicants' Fig. 3, 
for example, shows the sending side including Message Quota System 
separated the outbound message from the receiving side secondary message 
server 180. This distinction is further evident in the difference between the 
problem solved by the present invention and a different problem solved by 
Barchi. Applicants' invention protects a network service provider as follows: 

In doing so, the computer network such as the Internet is not subject to abusive 
spam email messages from computer user who have accounts (i.e., subscribe to 
network service) with a network service provider that uses the system of the 
invention. Accordingly, since message use is limit to required use (as imposed by 
a proper setting of the message limits for a particular originator identity), and not 
spam or junk message use, the domain associated with the network service 
provider is somewhat protected from being labeled as a "source of spam" on the 
computer network. In other words, conventional network service providers can 
become known sources of spam over time and thus computer users on the Internet 
might tend to configure their browsers to reject messages from domains 
associated with those network service providers. However, using the invention, a 
network service provider can protect itself from becoming labeled in this 
manner since the invention limits the amount of messages a user can send from 
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his or her network service provider. (Page 18 lines 1-14) (Emphasis added) 



In contrast, Barchi teaches an embodiment: 

"designed to analyze all incoming e-mail messages and detect high 
frequency e-mail either originating from a single user or destined to a single user. 
However, the embodiment can be modified to detect other types of undesired e- 
mail based on the pattern signature of such e-mail messages. The embodiment 
protects the receiving e-mail system not only against malicious users, but also 
against such events as routing accidents. Such an accident might occur if a user 
were to inadvertently configure a routing mechanism that routes prodigious 
quantities of e-mail to a single recipient in a very short interval of time." (Column 
5, line 59 - column 6, line 3) (Emphasis added) 

Additionally, Barchi teaches "Exceeding thresholds or certain ratios will 
trigger alarms to alert monitoring functions and update lists of known sources and 
types of undesired e-mail messages for filtering." (Column 5, lines 51 -53) In 
contrast, Applicants' invention specifically prevents a service provider from being 
added to the lists described in Barchi. 

The Office Action interjects the concept of an intermediary and interprets 
the term sending end to mean a terminal point in the email process instead of the 
originating side of the email process. Applicants' Fig. 1 shows both a sending 
side and receiving side. Applicants respectfully submit that neither the term 
"intermediary" nor "sending end" is used in any of Applicants' claims. 

As to the Office Action's assertions regarding routers, router accidents, 
and Applicant's alleged misinterpretation of both the claimed invention as well 
as the prior art references, Applicants respectfully submit that again, the Office 
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Action does not acknowledge the distinction between the distinction between 
sending/originating side and the receiving side of the email delivery process and 
the possible router placement. For example, in one embodiment of the 
applicants invention: 

The remote access server 150 may be, for example, dial-in network access 
server equipment such as a modem bank that allows computer users of computer 
systems such as the originator computer system 105 to dial-in to computer user 
accounts provided by a network service provider for access to the computer 
network 130. 

The authentication server 152 in this example embodiment is a 
RADIUS (Remote Authentication Dial-in User Services) server which executes or 
otherwise performs RADIUS authentication and accounting software functions 
according to techniques defined by Request For Comments 2138 and 2139 
(RFC2138 and RFC 2139), the contents and teachings of which are hereby 
incorporated by reference in their entirety. Generally, when a user of the 
originator computer system 105 dials-in or otherwise connects to the remote 
access server 150, the remote access server 150 interacts 170 with the 
authentication server 152 (e.g., via RADIUS authentication and authorization 
techniques) to authenticate and authorize access to a computer user account 
provided by the remote access server 150 for the computer user operating the 
originator computer system 105. 

Contrary to the Office Action's assertion, in this embodiment there is no router 
on the sending side which could create a problem repairable by Applicants 
invention. 

The above response notwithstanding, in order to expidite this application 
to allowance, Applicant has amended the claims to more clearly and distinctly 
define the claimed invention. 
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Regarding claims 1, 2, 12, 14, 15, and 26-29, 
The Office Action asserts: 

Stark . . .checks the physical IP address and the account to verify that the IP 
address matches one of the entries in the Informant Stylesheet, and if a match is 
found, the message is considered authentic, otherwise, rejected; [0047] The 
Informant Stylesheet defines information about the Informant or sender of the 
information and its valid transport sources or locations from where it will send its 
messages, i.e. identity of originator). Stark discloses a method for ...verifying an 
authenticity of an originator identity 

Applicants respectfully submit that Stark does not teach verifying an 
authenticity of an originator identity because Stark's use of an Informant 
Stylesheet which resides on the originator computer is not enabling since one of 
ordinary skill in the art would recognize that the Stylesheet can could easily be 
spoofed. 

Nothing in Stark is enabling as to verifying an authenticity of an originator 
identity. Any reference used to reject a claim must itself be enabling for the 
subject matter of the invention alleged to be taught (see In re Wilder ,429 F.2d 
447,166 U.S.P.Q. 545(C.C.P.A. 1970) and In re Collins .462 F.2d 538,174 
U.S.P.Q. 333(C.C.P.A. 1972)). For at least the reasons stated above, claims 1, 
2, 12, 14, 15, and 26-29 are patentably distinguishable from Stark in view of 
Barchi. 

Furthermore, Stark does not teach nor suggest "dynamically creating a 
valid account name and network address pair" as recited in amended claim 1, 
because Stark does not teach integration with a network service provider. It is 
unclear what Stark means by a "physical IP address" or how the system of Stark 
provides any real authentication. Whereas, Applicants' invention, for example in 
one embodiment, assigns the IP address after a login procedure and then uses 
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the assigned address to provide the valid account name and network address 
pair. 

The Office Action further asserts: 

Barchi disclosed ...performing a selective transmit operation including at least one 
of 

i) transmitting the outbound message onto a computer network if the message 
transmission result contains a transmit value; and 

ii) preventing transmission of the outbound message onto a computer network if 
the message transmission result contains a no transmit value (Barchi, col. 8, lines 
10-32. 

Applicants respectfully submit that Barchi does not teach transmitting the 
outbound message from the originating mail server" as recited in claim 1 
because Barchi operates on the receiving side and only triggers alarms in 
response to thresholds being exceeded. 

The Office Action states: 

The purpose for authenticating the sender of an email message in Starks is to 
prevent the use of the email system by malicious users. The purpose for the email 
usage pattern detection teachings of Barchi is to prevent malicious users from 
sending massive quantities of undesired email. (Emphasis added) 

Applicants respectfully submit that the Office Action mischaraterizes the 
teachings of Barchi. Applicants respectfully submit that it is not possible to 
prevent malicious users from sending massive quantities of undesired email and 
that unlike Stark and Barchi, Applicants' invention can prevent these undesired e- 
mail messages from being transmitted as outbound messages from the 
originating mail server onto a computer network. 

The Office Action states: 

Since both references teach acts of preventing unauthorized, malicious use of 
email systems (Starks, [0047]; Barchi, col. 3, lines 6567), it would have been 
obvious for one of ordinary skill in the at the time the invention was made to 
incorporate the email usage detection teachings of Barchi into the teachings of 
Starks in order to make sure that once a user's email is authenticated as coming 
from an original identity, that the user is not sending out massive amounts of 
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undesired email, i.e. spam, for the benefit of providing extra protection against 
users abusing the email system, in order to reduce or eliminate the volume of 
undesired email messages received by a computer system or server (Barchi, col. 
1, lines 10-13). 

In addition to the arguments above, Applicants contend that Stark and 
Barchi are not properly combinable. First, Barchi teaches away from the present 
invention. Barchi teaches identifying "undesired e-mail messages by receiving e- 
mail messages, storing fields including at least one field from the header of each 
received e-mail message and analyzing the stored fields for a least one pattern 
indicative of undesired e-mail messages." Barchi at col. 4, lines 58-67. Barchi 
teaches that received emails contain headers that are created when "a sender- 
SMTP establishes a two-way transmission channel with a receiver-SMTP." Id. at 
col. 1 , line 26 to col. 2, line 23. Barchi teaches methods that extract information 
from headers in incoming e-mail messages (i.e., received e-mail messages). 
See, for e.g., Id. at col. 6, line 7-8 ("For example, fields from the 821 header 
and/or the 822 header may be extracted in the Hunt Mode."). Accordingly, 
Barchi teaches operating on received e-mails only after a two-way transmission 
channel with a receiver-SMTP is established and the headers having the 
extractable information are created. 

The present invention, on the other hand, operates on outbound 
messages. The present invention, as a whole, has the benefit of not having to 
open up two-way transmissions to those recipients that exceed a message limit 
associated with the originator identity. Transmission only occurs to those 
recipients that do not exceed the message limit. 

Second, changing Barchi to operate on the sending side would destroy 
some of the purpose and functionality of Barchi. Barchi teaches protecting "the 
receiving e-mail system not only against malicious users, but also against such 
events as routing accidents." Id. at col. 5, line 64 to col. 6, line 3. Barchi can 
only protect against routing accidents if the mechanism is employed at the 
receiving side, after emails have been routed (i.e., transmitted). The present 
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invention, although providing benefits absent in Barchi, does not provide 
protection against routing accidents. This is because the present invention 
operates at the sending end, before emails are transmitted or routed. The 
present invention can reduce the number of emails routed by checking message 
limits associated with an originator identity and only routing those messages that 
are under the limit. However, once an email is transmitted in accordance with 
the present invention, any routing accidents can only be dealt with at the 
receiving end. 

Attempting to operate the methods in Barchi at the sending end would 
eliminate the ability of Barchi to protect against routing accidents, effectively 
destroying at least some of the purpose of Barchi. One of ordinary skill in the art 
at the time of the present invention would have no motivation to combine Barchi 
with any art (e.g., Stark) if the resulting combination would destroy some or all of 
the benefits of Barchi. 

Barchi also teaches detecting large numbers of e-mail messages sent to a 
single recipient. Id. at col. 7, lines 14-16 ("For example, for a list maintained for 
purposes of identifying undesired use in the form of many originators sending e- 
mail messages to a single recipient."). See also, Id. FIG. 6 and accompanying 
text ("The logic shown in FIG. 6 checks for whether the number of e-mail 
messages to a single recipient has exceeded predetermined threshold."). If 
Barchi is to be capable of counting all originators sending e-mail to a particular 
recipient, then Barchi must be operating at the recipient. If Barchi were moved to 
the sending side, then Barchi would only see messages intended to be sent to 
the particular recipient that originated at the sending-side server. Since it is well 
known in the art that there exist many sending-side email servers, Barchi, 
operating on a sending-side server, would only see a small fraction of the e-mails 
sent to the particular recipient, again defeating one of the purposes of Barchi. 
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For at least these reasons, claim 1 and the claims dependent therefrom 
are patentably distinguishable over Stark in view of Barchi. 

For analogous reasons, claims 12, 14, 26, 27 and 28-29 and the claims 
dependent therefrom are patentable over Stark in view of Barchi. 

Regarding claims 4 and 17, the Office Action asserts: 

Stark and Barchi disclosed the limitations of obtaining the originator 
identity includes the step of querying a login database containing mappings of 
originator addresses to originator identities based on the originator address 
obtained in the step of obtaining an originator address 

Applicants submit that checking the "physical" IP address on some 
Informant Stylesheet is not enabling as an authenticity check or equivalent to 
querying a login database since no login is required by Stark. Applicants submit, 
that neither Stark nor Barchi teach or suggest the limitation "querying a login 
database containing mappings of originator addresses to originator identities 
based on the originator address obtained in the step of obtaining an originator 
address." Stark uses a non-enabling Informant Stylesheet and requires no login 
procedure from the originator and Barchi is on receiving side so there is no login 
connection to the originator. 

The Office Action asserts: 

Regarding claims 9, 10, 22 and23 Stark and Barchi disclosed the 
limitations... of performing a selective transmit operation. 

As described above, Applicants respectfully submit Barchi does not teach 
transmitting the outbound message, therefore Barchi cannot teach 
"performing a selective transmit operation." 

The Office Action asserts: 

Regarding claims 1 1 and 24, Stark and Barchi disclosed the limitations... 
recording authentication information in a login database.... 
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Applicants respectfully submit Stark is not performing "recording 
authentication information in a login database" for similar reasons described 
above in conjunction with claim 4. 

Regarding claims 24 and 25, The Office Action asserts: 

Barchi disclosed ...the port redirector forwards the outbound message to 
the quota server (Barchi, col. 8, lines 1-45). 

Applicants respectfully submit, that the Office Action has not identified 
which reference teaches the port redirector recited in claim 24 and further that 
Barchi is completely silent on "a port redirector." 

Conclusion 

Applicants contend that it would not have been obvious to one of ordinary 
skill in the art at the time of the present invention to combine Barchi with Stark as 
suggested by the Examiner and that neither Barchi nor Stark teach all of the 
limitations of Applicants' claims. The Applicants respectfully submit that the 
claims are in condition for allowance and notification to that effect is earnestly 
requested. If the Examiner believes that a telephone conversation with the 
Applicants' representative would facilitate prosecution of this application in any 
way, the Examiner is cordially invited to telephone the undersigned at (508) 616- 
9660. 



Applicant(s) hereby petition(s) for any extension of time which is required 
to maintain the pendency of this case. If there is a fee occasioned by this 
response, including an extension fee, that is not covered by an enclosed check, 
please charge any deficiency to Deposit Account No. 50-3735 . 
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If the enclosed papers or fees are considered incomplete, the Patent 
Office is respectfully requested to contact the undersigned collect at (508) 616- 
9660, in Westborough, Massachusetts. 

Respectfully submitted, 



/Barry Gaiman/ 

Barry Gaiman, Esq. 

Attorney for Applicant(s) 

Registration No.: 42,562 

Chapin Intellectual Property Law, LLC 

Westborough Office Park 

1700 West Park Drive, Suite 280 

Westborough, Massachusetts 01581 

Telephone: (508)616-9660 

Facsimile: (508)616-9661 

Attorney Docket No.: ZIP00-01 



Dated: August 18, 2008 



